The complexity of modern integrated circuits (ICs) has led to the development of architecture-based designs, which use high-level design methods to decrease design time. A typical high-level design method uses an algorithmic description of the behavior of an IC to generate a register transfer level (RTL) description of the circuit. The RTL description is an intermediary level of abstraction between the behavioral and structural levels. The RTL description is produced by executing a plurality of design tasks such as scheduling, resource allocation, mapping behavioral statements to specific hardware components, and control unit generation. The design tasks work interdependently to produce a design scheme that represents the IC at multiple architectural levels. In such a design method, design errors can be introduced during the design both by the designer and by the automated design tasks.
Synthesis tools produce gate level netlists based on the RTL statements. Netlists generally include logical gates such as AND, NAND, NOR, OR, XOR, NXOR and so on. When a problem is detected at the gate level, usually, it is not an easy task to relate a gate level problem back to the original RTL code. In large designs, with hundreds of design files and numerous levels of hierarchy, finding in the RTL the precise cause of a gate level violation can be an impractical task.
An important part of the synthesis process involves designing for testability. Programs that aid in the testability process of synthesis are called design for test (DFT) processes. As part of DFT process, certain memory cells in the design scheme are replaced with special memory cells. These special memory cells, called scan cells, are designed to allow the application of test vectors to certain logic portions of the IC. Additionally, the special memory cells can be used to capture the output of the circuitry for observation and compare this output to the expected output in an effort to determine if circuit defects are present.
The portions of an IC that are designed to perform the intended or expected operational function are called its “operational mode” circuitry while the portions added to the IC to facilitate testability are called “test mode” circuitry or DFT implementations. The resultant circuit therefore has two functional modes, operational and test.
Bus contention is a problem that arises in an IC when more than one component contends for utilization of a single bus. Bus contention is a serious design problem, which should be eliminated to ensure that the resulting circuit operates as expected. In certain cases it is further necessary to detect a case where no source drives a bus, causing the bus to “float”. Moreover, it may be necessary to detect these conditions not only in normal operation mode but also in test mode, where the circuit behavior may be significantly different.
The conventional technique of detecting bus contention during simulation requires a skilled design or test engineer with knowledge of the waveforms representing the value on the simulated bus at various time intervals. The designer may realize that the abnormality is a result of bus contention. Conventional techniques may display such abnormal waveforms in color to bring the abnormality to the attention of the designer. Problems with this technique may arise if a contention exists only for a short duration.
In U.S. Pat. 4,744,084 (the 084 patent), Beck et al. suggests a system for performing hardware modeling, including that of bus contention. Through use of test vectors and optional timing analyzers they propose to detect design errors through dynamic simulations. Beck et al. suggests additional ideas for such dynamic simulations in U.S. Pat. No. 4,937,827 (the 827 patent).
A method for detecting bus contention during dynamic simulation is further described in U.S. Pat. No. 6,018,807 by Larson (the 807 patent). The method quite simply suggests that a dynamic simulation take place and a counting of the number of active enable signals on drivers to a bus are counted. When more than one is found to be in its active state an error is generated.
A method shown in U.S. Pat. No. 6,295,636 by Dupenloup (the 636 patent) deals with RTL analysis, including cases of contention detection. However, the method still requires simulation for detection of this error condition.
Like all the cases requiring dynamic simulations, these inventions require the extensive use of computer resources and time for performing the simulations. Moreover, the simulations are at best only as good as the coverage that the test vectors used provide, which is most likely unable to achieve a one hundred percent coverage.
Due to the significant amount of computer resources required when simulating circuits it is often advantageous to emulate a circuit on some hardware, for example as suggested by Bailey in U.S. Pat. No. 5,872,953 (the 953 patent). Bailey suggests a method to transform the circuit from its original description into a description that allows for emulation of the same circuit. This of course will result with a significantly accelerated response time.
The quality of the result (i.e., detection of errors) is, however, still limited to the selection of the test vectors and the errors that they may detect. It should be understood that the use of test vectors does not necessarily mean a one hundred percent test coverage.
Since not all the errors can be detected using test vectors, Fister et al in U.S. Pat. No. 6,324,657 (the 657 patent) suggest the inclusion of a hardware circuit as part of an IC for detection of errors, including that of contention. However, the error is to be detected at a very late stage of the design, i.e. in the early manufacturing stage.
Another method of detection involves formal methods but these typically require user setups. Furthermore, such setups may become complex if they are to detect kinds of contention that may happen only in test mode. Kucukcakar et al., in U.S. Pat. No. 5,907,698 (the 698 patent), propose such a method. It involves the comparison of the RTL description to the architectural design rules. If the RTL description is found not to be coherent with the architectural design rules then an error is indicated. These types of checks can detect inconsistencies in architectural implementation, however, they do tend to be complex and are generally less efficient in detecting lower level errors such as potential bus contentions.
Another technique for detecting contention provides a method for determining whether a contention condition exists on a simulated bus by checking whether two or more drivers connected to the bus are active. U.S. Pat. No. 5,373,514 by Ma (the 514 patent) provides additional assistance by adding detection logic connected to both the bus having a contention as well as the enable signals of a driver.
Nevertheless, the operation still requires a dynamic simulation through the use of a plurality of test vectors. Using the method in test mode results in additional complexity as the detection circuitry has to be modified to address this state as well.
Frequently, in order to reduce the complexity of test vectors in test mode, circuits are broken along scan lines. This allows for testing of just portions of the circuit, hence reducing significantly test time and test complexity. U.S. Pat. No. 5,903,466 by Beausang et al. (the 466 patent) suggests such a solution. However, it still does not eliminate the need to dynamically simulate the contention or float situations of a bus, and while complexity was reduced it is available for test mode which is still either time consuming for simulation, or requires tests on the actual or emulated hardware.
A totally different approach is proposed by Pawlowski in U.S. Pat. No. 6,243,777 (the 777 patent). Pawlowski suggests that a circuit be added to the output of two enable signals for detection of a possible contention where both signals enable drivers to drive a single bus. The additional circuit outputs a signal connected to the logic creating one of the enable signals and delaying the output of that driver. While a solution for prevention of contention in some cases, where time separation is a feasible solution, it is not a solution for the general case of detecting and preventing bus contention.
Therefore, it would be advantageous to have a solution that detects bus contention and identifies the contention introduced at an early stage in the design. It would be further advantageous if the provided solution will be DFT compatible, i.e., preventing bus contention in general and in test mode in particular.